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Abstract 

The rapid introduction of digital mobile communications 
systems is an important part of the emerging digital 
communications scene. These developments pose both a 
potential problem and a challenge. On one hand, these 
separate market driven developments can result in an 
uncontrolled mixture of analog and digital links which 
inhibit data modem services across the mobile/Public Switched 
network (PSTN) . On the other hand, the near coincidence of 
schedules for development of some of these systems, i.e., 
Digital Cellular, Mobile Satellite, Land Mobile Radio, and 
ISDN, provides an opportunity to address interoperability 
problems by defining interfaces, control, and service 
standards that are compatible among these new services. 

In this paper we address the problem of providing data 
services interoperation between mobile terminals and data 
devices on the PSTN. The expected data services include G3 
Fax, asychronous data, and the government's STU-III secure 
voice system, and future data services such as ISDN. We 
address a common architecture and a limited set of issues 
that are key to interoperable mobile data services. We 
believe that common mobile data standards will both improve 
the quality of data service and simplify the systems for 
manufacturers, data users, and service providers. 

Introduction 

We are witnessing a revolution in our communication networks 
infrastructure. After a century of reliance on analog based 
technology for telecommunications we now live in a mixed 
analog/digital world and we are rapidly moving toward all 
digital networks. Mobile communications which includes 
Cellular Telephone, Mobile Satellite, Land Mobile Radio, and 
portable telephones the are fastest growing component of the 
communications industry and are highly dependent on digital 
techniques. Quite independent of the use of digital 
technology in the network is the steady advance of data 
communications in the business and personal world. Today's 
modem based data communications connect an ever growing 
number of PCs, Fax and STU-III users. Unfortunately, the 
intersection of these major trends, mobile data services, 
requires special accommodation by the networks as simplicity 
and transparency of analog communications are lost. 
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A Common Architecture 


Today's mobile networks are characterized by a maze of 
sophisticated techniques and associated standards which 
address the unique features, channels, control, and switching 
functions of the various mobile networks. To expect a single 
standard for such complex and diverse applications is naive. 
However a segmentation of the network features into layers as 
has been proposed by others. Reference [1] separates out the 
network unique transport layer and identifies interfaces 
which are common to mobile networks and suited to 
standardization. One such view of mobile networks can be seen 
in Figure 1 which shows how cellular and satellite networks 
share common features for data users. Both cellular and 
satellite networks will have unique features to support 
operation over the very different radio channels. The 
interfaces however at the mobile terminal, and at the network 
interface have quite similar properties and functions. Both 
must support a compatible transition from the radio link 
digital protocol to a compatible PSTN modem protocol. Each 
must deal with detection of control signals and functions 
which enable transition to and from the data mode into voice. 
Finally both networks operate with compressed voice at rates 
below 9.6kbps, and will not directly support analog modem 
signals. Another view of these same networks is presented in 
Figure 2 using the CCITT reference model for mobile networks 
and interfaces. It is significant to note that all mobile 
connections of interest operate across two very different 
networks. Here the functions and interfaces for satellite and 
cellular networks appear common and they could in fact be 
common. Such models, although insightful, do not replace a 
detailed specification of interfaces and protocols necessary 
to insure compatibility. This must happen in standards bodies 
and reside in detailed standards. What is necessary and can 
be accomplished here are the identification of the issues 
which will drive the selection of standard solutions. These 
are presented below in the interest of forging a common or 
perhaps standard solution across the many networks. 

Interoperability Issues 

Initiation of Service 

At first glance the initiation of data service is simple. If 
the initiation is negotiated by voice, the mobile terminal 
signals the network interface to invoke the interworking 
function or modem pool. More difficult problems exist however 
if the service is initiated from the PSTN device or when the 
devices are not attended. Most PSTN initiated functions will 
be accompanied by a control tone such as the 2100 Hz tone 
used by Fax and STU-III. A common solution to all of these 
situations is to place the data mode initiation and release 
at the mobile unit. If the mobile unit monitors the analog 
traffic with a tone detector, the switch to data is 
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straightforward. Likewise if the mobile is unattended it can 
be strapped for immediate initiation of data service. This 
solution can only be accommodated if the voice coder used on 
the radio channel can reproduce the control tones with 
sufficient fidelity as to assure reliable detection by the 
mobile unit. This has been tested for the IS-54 VSELP coder 
as well as the Fed Std 1016 coder and should be a validated 
feature of other mobile network coders using this scheme and 
bears further investigation. Other schemes have depended on 
switching of services by initiation at the network interface. 
These approaches are limited by the need to identify the 
service provided by dialed number, or by maintenance of a 
data base, or the need for two stage dailing. These 
approaches result in a solution which may be either too 
awkward or too limiting. For this reason the mobile initiated 
solution is recommended as a standard for the various mobile 
networks . 

Data Interface and Control 

When viewing the CCITT reference model in figure 2 from the 
perspective of data services, the mobile network represents a 
"digital pipe" supporting some user defined service into 
another network interface. The user's interface needs can be 
totally defined by a specification of: 

1. interfaces between the data device and the mobile 
define as the Sm interface 

2. the interface between the mobile and the Base Station 
(BS) defined as the Um interface and 

3. the interface between the Mobile Switching Center 
(MSC) and the Interworking Function (IWF) . 

It simply remains to define the form of the interface, the 
list of control functions and the protocol for communicating 
control. Following todays standard conventions we would 
recommend standards for physical and data protocols as shown 
in Table 1. 


Interface 


Physical Layer 

Data Layer 

Mobile/Data 

Sm 

RS-232C 

X .25/synch 

Mobile/Base 

Um 

N/A 

Service Unique 

MSC/ IWF 

L 

RS-23 2c 

X. 25/synch 


Table 1 . : Proposed Common Mobile Interface Standard 
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The selection of these conventions are clear with the 
exception of the data layer. Here we are mixing an X.25 
protocol which is synchronous with a sychronous mode. No 
convention appears to be established for such a case. 

Given the interface definition and data protocol, there 
remains only the definition of the message types necessary to 
initiate and support the service. The first of these would be 
messages to initiate data service by selecting an 
Interworking Function. A message format suited to this 
function is shown in Figure 3 which includes a list of 
typical selections for the various data fields. 


Similarly when connected to an interworking function, a 
common set of service features would be selected as shown in 
the message format suggested by Figure 4 . 


Use of Primitive Data Service Features 

The complexity of providing unique data services such as the 
G3 Fax or the STU-III is not apparent from the control 
features identified above. In both cases there is a complex 
interactive set of protocols which propagate into the network 
functions to support the service. There are for example rate 
negotiation signaling and rate changes that must be reflected 
in the radio link operation. In order to remove the 
complexity of this operation from the link protocols, and to 
maintain a layered structure, the recommended approach for 
such data service is to build these services using primitive 
data service features such as those defined in Figure 4 . In 
this case the radio link is controlled by the mobile data set 
and the interworking function through a sequential set of 
appropriate primitive data features to accomplish on the 
radio link the equivalent of the functions accomplished in 
the PSTN modem link. This allows a limited set of data 
primitives to accomplish a wide range of applications. The G3 
Fax and the STU-III for example both have synchronous data 
operation at 2400bps and 4800bps. Figure 5 shows how a G3 Fax 
connection would be made through the mobile and PSTN networks 
using the primitives in Figure 4 . Although these are quite 
different standards on the PSTN modem link, they can be 
identical protocols on the radio link. 

Interworking Functions 

The role of the Interworking Function shown in Figure 2 is 
crucial to the operation of data services across mobile 
networks. These components perform all the necessary 
functions to translate the protocols and controls from one 
network to another. Whenever one encounters such a function 
in a network it is wise to examine the potential complexity 
that awaits the naive designer. As most of the Interworking 
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Functions will service modem connections these components are 
often referred to as modem pools. Ideally there is an 
Interworking Function for each modem or system protocol 
offered but in practice these are aggregated into 
multifunt ional programmable devices. Selection of an 
interworking function as proposed above will invoke a 
particular protocol set. This must include procedures for 
accommodating all of the control signals, rate negotiation, 
channel conditions and timeouts associate with the 
Interworking protocol. The challenge to network designers is 
to incorporate as many Interworking Functions possible with 
a minimum of complexity. For a satellite network an 
Interworking Function will be located at the satellite ground 
station. For Cellular applications the implementation of the 
Interworking Function is complicated by the diversity of 
locations. A requirement to support many Interworking 
Functions at a large number of Mobile Switching Centers could 
be costly and inefficient. The availability of a standard (L) 
interface as proposed in Table 1 offers the opportunity to 
centralize this service as shown in Figure 6. Here a T1 
connection between the MSC and a remote Interworking Function 
can support multiple unique data services without directly 
supporting an IWF at each MSC. 

ISDN Interface 

Important among Interworking Functions is the interface to 
ISDN services. This special interface represents the gateway 
to the future all digital networks and must be carefully 
planned to assure future data service interoperability. Much 
of the ISDN Interworking Function requirements are define in 
CCITT Standard V.110. In addition to protocol issues the 
major functions addressed in this interworking function are 
rate adaption, synchronous and asynchronous operation and 
timing. The IWF defined by V.110 accommodates all conversions 
of modem bit rates of 75x2 n and multiples of 4000bps to 
either 56000bps or 64000 bps. Timing adjustments are 
addressed for asynchronous data. Timing for synchronou data 
however requires that clock be accepted by the connecting 
network . 

Synchronization and Timing 

Timing and synchronization are critical to data operation on 
mobile networks . Briefly, the issues fall into two 
categories : 

(1) Timing issues, which must be dealt with when 

synchronous data service connections must cross network 
boundaries or cross boundaries (e. g., in handoff) 
within the digital cellular network, where different 
clocks are controlling timing on opposite sides of a 
boundary . 
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(2) Loss of bit count integrity, e. g., as a result of 
losing a frame in a handoff. 

Here we suggest an approach which might be taken to dealing 
with timing and bit (and frame) count integrity problems by 
incorporating appropriate control information into the 
transmission frame structure for applicable data services. 

The basic concept is to insert frame count (and possible 
clock timing) information into the channel at uniform 
intervals tied to the overall frame structure. This 
information, carried with the frames throughout the mobile 
system, can be used to resolve frame count ambiguities and 
clock timing inconsistencies. 

Synchronous operation can be maintained across handoffs using 
a simple frame count technique. It is assumed here that 
frame synchronism is maintained between any base station and 
the MSC, but that synchronism is not maintained among base 
stations. As a consequence of this, a single frame can be 
lost on handoff. If the frame count ambiguity is in fact no 
more than plus or minus one frame, a modulo-4 counter 
(needing two bits of information) can be used to resolve the 
ambiguity and reconstruct the synchronous data stream when a 
frame is lost. The implementation would make use of elastic 
buffers at the MSC and at base stations. 

The frame count information could be used to implement a form 
of "soft handoff". As a mobile is approaching handoff from 
one base station to a new base station, the frames could be 
sent to both the current base station and the new base 
station. As the handoff occurs, the mobile could use the 
information from the two base stations to resolve the timing 
differences and achieve a smooth handoff with no dropped 
frames . 

Figure 7 gives a simple example of a frame structure 
incorporating a frame count field in each frame. In the 
example, rate-3/8 FEC coding is applied to the 4800 bps data, 
leaving eight bits for the FRAME COUNTER field, which we show 
as being coded separately from the user data. If a simple 
modulo-4 frame count is to be used, an (8,2) binary block 
code can be used to protect the two information bits. If 
more information is to be incorporated into the field a 
different code may be appropriate. 

For FEC coding of the user data, either block or 
convolutional coding could be used. However, block coding 
might prove to be more convenient to use in conjunction with 
the frame counting and timing adjustment techniques suggested 
here . 

The basic scheme described above can be used to convey clock 
timing information in addition to frame count information. 
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In this case, the information content of the FRAME COUNTER 
field is expanded to include clock timing information. Given 
this expanded use for the field, SYNC CONTROL might be a 
better name. As one example, a clock timing offset between 
the MSC and the synchronous terminal in the PSTN could be 
accommodated with buffering and a stuff /unstuff algorithm. 

The corresponding short/nominal/long adjustment information 
would be carried in the SYNC CONTROL field. The inclusion of 
timing information in the frame format would require passing 
more information than was indicated in the discussion above. 
This would mean expanding the information content of the 
control field, and perhaps expanding the overall length of 
the field as well, in order to provide the desired radio link 
error protection.. This would be accommodated by reducing 
somewhat the number of parity check bits allocated to FEC 
coding of the user information. Since the size of the 
overhead field will in any event remain relatively small, 
this should have little impact on provision of adequate link 
error protection for the user information field. 

An approach similar to this is described in a recent 
conference paper by Shinagawa, et. al. [2], In that paper, a 
digital mobile radio system under development by NTT is 
discussed. The paper includes a description of a "hitless 
handover" scheme in which clock signal information is affixed 
to TDMA frames and passed between base stations and switching 
centers . 


Conclusions 

Fulfillment of the potential for Mobile Networks will only 
come with careful attention to accommodating the future needs 
of users. Data services represents a critical component of 
future mobile service but has received little attention as 
today's networks are being designed against near term 
objectives of expanded voice service. In this paper we have 
outlined a common archetecture for mobile data services and 
have suggested several reference points in the archetecture 
that are candidates for standardization. By adopting standard 
interfaces at the present time when new digital initiates are 
in the design stage, data service interoperability across a 
wide variety of networks can be assured. 
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Figure 1. A Common Architecture for Cellular and Satellite 



Figure 2. CCITT Reference Model for Mobile Networks 
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* Message Type * Service * Option (N) 


Initiate IWF G3 Fax ARQ 

Release IWF Modem Pool Modem Type 

Request to Send Async data Duplex 

Clear to Send Synchronous Data 

Service Busy STU-III 

Service Denied Raw Channel 

Revert to Voice 


Figure 3. Selection of Interworking Function 


^Message Type 

*Rate 

*Sync 

*ARQ 

*EDAC 

*Delay* 

Service Feature 

300bps 

async 

ARQ 

1/8 

Short 


1200bps 

synch 

No ARQ 

1/4 

Medium 


2400bps 



1/2 

Long 


4000bps 



3/4 



4800bps 

7200bps 

8000bps 

9600bps 



CRC 



Figure 4. Selection of Service Features 
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Figure 5. G-3 Fax Connection on Digital Mobile/PSTN Network 
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40 ms - 520 BITS AT 1 3 KBPS J 
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Figure 7. Example of a Frame Count Scheme for a 4800 bps Synchronous 
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